Magnum One

home *** CD-ROM | disk | FTP | other *** search

/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d20 / tick207.arc / TICK130.DOC < prev

Wrap

Text File | 1991-02-08 | 58KB | 1,219 lines

TICK v1.30 What is it? Tick is a program which does for files what echomail does for messages. It was largely inspired by the program "Flea", by Ron Bemis. Tick picks up on that concept, and adds to it. Using any ASCII editor, you set up a configuration file to tell TICK about your system and to set up file echo areas. TICK then looks in your inbound area for received TIC attaches, tosses them to the echo-area directory you specify, appends the FILES.BBS in that area, and optionally echos the files to other systems you specify. If your BBS doesn't use a FILES.BBS, you can have TICK create a user- customized file-list in the format you would like (so long as it's ASCII). You can set up different areas for different file-echos, much as you may have many echotags in echomail. In each file-echo area, you may list up to 40 nodes to which you echo the files. The program establishes passwords which are used to verify that the files you receive are from the node you expect them to be from. You may also specify which nodes in a file echo are allowed to send you files, which may only receive files from you but not send them to you, or which nodes may send you files but never receive them from you. TICK will allow you to configure so that it creates FLO file at- taches for mailers such as Binkley and Opus, which use them, or MSG attaches for Seadog-type systems that use that kind of attach. This second method is referred to as "FIDO" mode within TICK. When TICK creates an attach, it sends both the desired file, and a small control file which contains seenby and other information. The preferred in- formation file is the TIC file, which is defined in FSC-0028. TICK will also generate the FLE file format for communication with FLEA. The choice of which file format to use may be made for each echoed system, independently of other systems echoed. You may set TICK to receive both TIC's and FLE's, or have it process only TIC's received. The choice of which file format you send to other nodes is independent of which file format you received with the original file. Files are entered into an echo using the companion program HATCH. HATCH uses the same configuration file as TICK. If you are upgrading, please skip to "WHAT'S NEW" before reading further. If you are setting up TICK for the first time, read on. WHAT DOES IT DO When TICK operates, it looks for inbound files with the extension TIC (or FLE). These are "control" files which tell the program what the name of the "real" file is, the echo area it is to go to, and what systems have already seen the file. The information is checked against the configuration file, and if passwords match and the area exists, the file is tossed to the "destination directory" established 1 TICK v1.30 when the AREA was set up. (The file is moved to the destination direc- tory by renaming it if it is possible, or by copying and deleting the original if it is not possible). The FILES.BBS in that directory is appended with the description (again, part of the TIC file). If there are other nodes listed for that echo, TICK will then create new TICs or FLEs for them, and will create FLO files to those nodes in the out- bound. The FLOs will send the new TIC and the "real" file to the other nodes. This does NOT happen if that node is already listed in the seenby line of the original TIC. TICK should be called in your batch file after receiving files. It is designed so that you may redirect its output to the Binkley.log, Opus.log, or to a log of its own. In the simplest form, the command would look something like this: TICK >> Binkley.Log If running from a shell (not suggested), it would be preferable to use a separate log to avoid problems of writing to a file which may already be open. THE CONFIGURATION FILE Before TICK or HATCH can run, you will need to create a con- figuration file to tell the program about your system, select optional parameters, and to establish file-echo AREAS. Each AREA (you may have many) is equivalent to a different echo area in echomail, and lists the nodes that you receive from and send to. The addresses of the nodes are zone aware. The brackets indicate optional items, and should NOT be entered in the real configuration file. The format of the configuration file follows: IN c:\file\inbound (This specifies the inbound area) ZONE 1 c:\opus\outbound (This specifies the Outbound area) (The FIRST Zone is the DEFAULT Zone) ZONE 2 c:\opus\outbound.002 ZONE 3 c:\opus\out3 (Zones need not follow Binkley style) NET 266 (Your Net) NODE 12 (Your Node) HOLD c:\holddir\ (Where outbound TICs and FLEs are kept) QDIR c:\qdir (MUST be defined - not yet used) 2 TICK v1.30 [ListFmt %3:-13 %1] (Alters the default format of the FILES.BBS) [ListName Files.Bbs] (Alters name and/or location of FILES.BBS) [AKA 1:1/313] (Adds your AKA addresses to the Seenby lines) [AKA 5:678/90] [STOPDUP [c:\tickdir]] (Optional parameter, turns on Stopdup feature - Specifies where DUP files are to be kept) [QUIET] (Optional - Stops beeping on fatal error) AREA c:\file\ticktest TICKTEST Local ListName c:\files\RBBS.LST 1:266/1 Passwrd1 [FLAGS] (Where flags = [*][&][F][C|H][An]) 2:512/26 Pass2p [TEMP c:\ramdisk] (Optional directory for temporary files) [FIDO] (Send files as MSG attaches instead of FLO attaches) [MAIL c:\netmail] ( Location of Netmail - Required if FIDO specified) [FLEA] (If present, tells the program to also process inbound FLE files) [LOGPATH] (If present, log the PATH lines to the logfile) [LOGSEEN] (If present, log SEENBY lines to the logfile) [CRC] (Enable CRC testing) [LogCRC] (Place copy of CRC in the log) [Crc2Dup] (Place copy of CRC in the DUP file) [NoWait] (Prevent HATCH's re-prompt for bad FILEname or AREAname) The brackets indicate optional items, and should NOT be entered in the real configuration file. Now ... an item by item description: 3 TICK v1.30 IN c:\netfile This entry should point to the inbound files area. Directory entries in the TIC configuration file may be entered with or without trailing backslashes, and must reference an ex- isting directory. ZONE 1 c:\opus\outbound This specifies the Outbound area for zone 1. TIC allows multiple zones in multiple outbound areas (Binkley style). The ZONE line may be repeated for as many zones as you are communicating with. THE FIRST ZONE STATEMENT MUST REFERENCE YOUR OWN ZONE, and is used as the default zone when a control file (TIC or FLE) does not contain a specified zone. The control file must have at least one ZONE line. ZONE 2 c:\opus\outbound.002 This tells the system where to place FLO files for zone 2. Note that a directory must be declared for each zone you plan to address, even if you run FIDO mode and don't create FLO files. ZONE 3 c:\opus\out3 The directory must be specified for each zone. Tick does NOT assume that zones other than your own are named the way they are done in Binkley. NET 266 This line must contain your primary net number, and is re- quired. NODE 12 This line must contain your primary node number, and is also required. (In a future release, I'll change this so you can just specify your address as NET/NODE on the same line). HOLD c:\holddir\ This specifies the location of the "HOLDing" direc- tory. This is where the outbound TIC and FLE control files are stored until your mailer sends them. It also will be used by fu- ture TICK versions to hold other information as well. This directory is maintained by TICK, and should not contain other files. Know what you are doing before changing anything in this directory. QDIR c:\qdir This directory should be a separate directory and should contain nothing. It is not yet used, but MUST be declared. It will have a use in a future version of TICK. [ListFmt %3:-13 %1] This optional entry allows you to alter the default format of the "Files.BBS" file that TICK has always created. The format may be compatible with TBBS, RBBS, and nearly any other BBS that uses an ASCII file as a files list. Additional description is below. The numbers shown in this ex- ample are the default parameters used if you do NOT declare a ListFmt. 4 TICK v1.30 [ListName Files.Bbs] Just as TICK may give you a different format for the FILES.BBS, it is not restricted to the name "FILES.BBS". It is possible to have it called by any legal dos filename. You may locate the file in any directory, rather than the same directory that the files go to, and you may specify that ALL descriptions go to the SAME file is that's what you require. (See more below). [AKA 1:1/313] [AKA 5:678/90] These entries direct TICK to add these nodes to the Seenby list. It is now possible to establish a link with chosen nodes using the AKA address instead of your main address. (See more below.) [STOPDUP c:\tickdir] This optional line, if present, activates a function similar to the STOPDUP program I had written to help limit duplicate files from being passed by Flea. What it does is to keep a list of all filenames processed in each echo area. Whenever a new file is received in an echo area, the filename is compared to all names in the list. If that name has previously been seen, the incoming TIC or FLE file has its extension renamed to BAD, and the received file is ignored. If you later decide that the file should be passed anyway, you may rename the BAD file back to TIC or FLE, and delete the filename from the ap- propriate ECHONAME.DUP file. The next time TICK is run, the file will be passed. As implied above, when STOPDUP is specified, TICK keeps a file in the specified (or default, if none is specified) directory for each echo area you have set up. If the echotag is "NODELIST", then the file name is "NODELIST.DUP". [QUIET] If this is not present, TICK will beep should it need to abort with a fatal error. Non-fatal errors will not cause a beep in any case. AREA c:\file\ticktest TICKTEST Local ListName c:\files\RBBS.LST 1:266/1 Passwrd1 [*][F][&][[H][An] or [C]] 2:512/26 Pass2p This structure is used to define the echo areas. It is analogous to the AREAS.BBS used by confmail. For each echo, you use the keyword AREA, followed by the directory, followed by the echotag. The following lines are in the format shown above, con- sisting of ZONE:NET/NODE PASSWORD FLAGs. There may be up to 40 such addresses lines present in each AREA. An AREA ends at the first line NOT in the ADDRESS PASSWORD format, such as a blank line. The exception is that lines beginning with the keyword "LOCAL" do not end an area if they immediately follow the AREA line. These LOCAL lines are used to establish special treatment specific to that area only. 5 TICK v1.30 The password is the password used for that particular node, and may be up to 8 characters. It is case insensitive. The other node must specify the same password for your node in his TIC.CFG file. The "*", if present, specifies that you will ac- cept files coming from that node. If not present, you may send files to that node, but will not accept them from him/her. The "&", if present, tells TICK and HATCH to ignore that node when sending files. Files are never sent to a node which has the "&" flag. If combined with the "*" flag, that node be- comes a "receive-only" node. You will accept file coming from the node, but will NOT echo files TO it. If the "&" flag is present but the "*" flag is NOT present, the node may neither send nor receive from you, and is effectively commented out without ending the area. It is possible to tell TICK to generate CLO and HLO files directly, or to generate FLO files as the default. The way this is done is to append a "C" for crash or a "H" for hold as the last token in the system you are connecting to. The "C" and "H" are mutually exclusive. If you attempt to use them both in the same line, TICK will issue a warning, and will treat the system as a HOLD. If you are running in the FIDO mode, the MSG produced should have the Crash or Hold bits set as appropriate. In the Non-Fido mode, FLOs, CLOs, or HLOs are produced. The Address and password are separated by whitespace, as are the password and flag fields. The FCH*& flags are in any order, but are contained in a single "word". They must NOT be separated from each other by spaces. The "F", if present, may be upper or lower case (as may be the C or H), and specifies that you will send Flea compatible files (FLE extension) to that node (instead of sending TIC files). The format of the received file is irrelevant. The "An" flag takes the form of the letter "A", followed im- mediately by a single hex number ranging from "0" to "F". This is used to designate that an AKA address is to be used in the link to the node declared on this line. Further description is below. The AREA statement, as mentioned, may have up to 40 nodes listed for each echo. You may repeat the AREA statement for as many echos as you carry. The statement is considered to end at the first line which is not in ZZ:NET/NODE PASSWORD form. (The LOCAL lines are a partial exception to this rule). 6 TICK v1.30 [FLEA] This statement tells the program that it is also to process any inbound FLE files as well as TIC files. The default is to process only TIC format. (Again, you may SEND either format regardless). [TEMP] c:\ramdisk This allows you to specify where TICK will write its temporary files. Choosing a ramdisk here will speed up the processing. If this is not included in your CFG file, TICK will use the default directory for your temporary files. [FIDO] What this will do is to have TICK create MSG attaches rather than FLO files. (See WARNING below!) This should then force TICK to handle attaches to messages rather than creating FLO files. The TIC's and FLE's are still placed in the outbound. The code will try to put both file attaches in the same message if there is room. If the combined length of the paths and filenames exceed the 72 byte field allowed, two messages will be created instead. The created messages will have the killsent flag set, so that your mailer may kill the message once it is no longer needed. I am assuming that whatever software you are run- ning will respect the "killsent" flag and delete the MSG file which "points to" the TIC of FLE in the outbound. What TICK does is to find all MSG files which are file attaches, local, private, have the killsent flag set, and are from "TICK .....". It takes the subject lines from MSG's meeting these criteria, and writes them to a temp file. It then looks at all TIC's and FLE's in the outbound(s). Any which do not have an active MSG attach are con- sidered "orphans" and are deleted. WARNING: DO NOT RUN TICK IN THE FIDO MODE IF YOU HAVE ANY TIC'S OR FLE'S IN THE OUTBOUND WHICH ARE "POINTED TO" BY FLO FILES. TICK will find no MSG attach, assume that the TIC/FLE's are or- phans, and delete them! [MAIL c:\netmail] This entry is REQUIRED if you are running in the FIDO mode. It allows TICK to find your netmail directory for MSG's. If you do NOT use the FIDO mode, this entry is not needed. [LOGPATH] If present, path information (present in the TIC format files) will be sent to your log file for future reference. This is useful in determining topology. Also, since the time and date that each system processed the file is included in the PATH, this allows you to see how much delay was encountered on each leg of the trip. 7 TICK v1.30 [LOGSEEN] If present, all seenby lines in the received TICs or FLEs are also logged to the LOG file. This results in very large logs, and is only intended for debugging and finding problems. [CRC] Tick generates a CRC-32 on all files that it processes. If you include CRC in your CFG file, the CRC in the inbound TIC file will be compared to the one calculated. If they don't match, the file will be failed. [LogCRC] If this is in your CFG, the CRC-32 will be logged to the logfile. [Crc2Dup] This will cause the CRC-32 to be stored in the DUP file. It doesn't do anything now, but might be useful in the future. [NoWait] This prevents HATCH from looping back for new input when you enter an incorrect FILEname or AREAname. All lines other than the ZONE and AREA structure lines may be in any order, and need not be left justified. Unknown lines are ignored. Defining a FILES.BBS-type file Thanks to a lot of help from Bob Hartman, TICK will support the file-list format needed by many different BBS packages. If you don't do anything special, the defaults will be to establish a file-list file called "FILES.BBS" in each "toss-to" directory. (The "toss-to" directory is the directory that is associated with an AREA, and to which the received file is tossed). * Bob Hartman has provided a great deal of the code to allow mul- tiple formats of files.bbs files. Following is the description provided by Bob. You can set the output format of the files.bbs file by adding a line to your config file with the keyword "LISTFMT" fol- lowed by the format you desire. -------- Any character not proceeded by a % is just put into the string. If the character is a %, then the stuff following it is interpreted as follows: y stands for the length of the field to use. If it is a negative number, then it is meant to be left justified. A positive number is right justified. If it does not appear, or is zero, then the field is considered to be unlimited. 8 TICK v1.30 z stands for special processing. The first one defined was '1', and it is used only in the file description for TBBS systems. It will append a return and an exclamation point and then continue the description. This is for TBBS 'linked comment' fields. 2 and 3 are also now defined, and are described below. %x[:y[.z]] (y = LENgth of field, z = "specification") where x is 1-7 (or 100) and stands for: 1 - file description 2 - path to file with trailing backslash (that is correct isn't it?) 3 - actual file name 4 - file size 5 - date as mm-dd-yy - There are changes here. If you simply specify this as "%5", you will get the "file- date". If you specify it like this: "%5:8.3", you will get the SYSTEM date. This should be helpful for RBBS boards, and others that need to list the date received, rather than the file-date. 6 - Day-of-the-week - This will give you the day of the week (spelled out fully) if you specify "%6". This is the day the FILE was created. If you want only the first 3 characters (as in "Mon", "Tue", etc), then specify it as "%6:3". If you want the SYSTEM day-of-week, then specify it as "%6:3.3" for the 3 character string, or as "%6:0.3" for the full string. (A length of "0" is interpreted as an unlimited field). 7 - Hex CRC value for the file. 100 - See below. So, for TBBS systems, the file should look like: full_path_name file_name description(40 chars+linked comments) and the line format would be: %2%3 %3 %1:-40.1 For RBBS it would be %3:-12%4:9 %5 %1:-43 001 where the 001 would be whatever file area they wanted to specify. 9 TICK v1.30 For Opus systems it would be: %3:-13 %1 (which is the default if you don't set the ListFmt descriptor in the CFG file. Now for the really fun part! There is another value x can take. The format %100:y.z is used to set up special wrapping for long com- ment lines. Here is a portion of the description Bob sent me. %100 is very new. It is used to set the indent and the first in- dent character for overflow lines. The length parameter (after the colon) gives the indent length, while the specification parameter (after the period) gives the ASCII value for the first character of the line. It is probably wise for people to make this the first thing in their format string if they wish to use it (otherwise they may have wrapped before it gets evaluated). For example, Opus systems might want: %100:1 This makes it a single space as indent (or) %100:20 which would give a 20 character indent. They can also do wild things like: %100:20.45 which (I think) will output 20 spaces on the new line, but after a '-' is put there first. %100 comes into play whenever the specification type of a parameter (the field after the period) is a 2. TBBS uses a 1, while this new stuff uses a 2. I imagine that descriptions are the most likely place for it to be used. TBBS needs two special characters for the continuation line, so it cannot be done using the %100 instead. Of course, this makes things VERY interesting, and very tricky. It is easy for people to screw i up, so recommend that they experiment. It is all automatic for TBBS systems, but for others, this hopefully gives them the ability to do what they need. One interesting sidenote. When using a length with either the TBBS .1 or other style .2 specification, the length given is used on ALL lines. For example, using %1:-40.1 as in a TBBS style line will break the description into a 40 character block, add \n!> (tbbs specific), then add the next 40 characters of the description (and repeating if necessary), padded out with spaces if necessary! This way things always remain in the correct columns if necessary. It shouldn't matter. If people complain, then it might be able to change it later on. For Opus, try this: ListFmt %100:31%3:-12 %1:-48.2 10 TICK v1.30 That tells TICK to set indent at 31 spaces for wrap-around. The first entry in the line is the filename (which starts flush against the left, hence there is no space after the "31"). The filename field is left justified, and occupies 12 characters. It is followed by a space and then the DESCription, which is left justified, occupies 48 spaces, and will wrap to the next line inset by 31 spaces. The wrap feature is not polished. It will wrap at the specified length even if it comes in the middle of a word. * You now have the option of having the file created called some- thing other than "FILES.BBS", by using the keyword "ListName". * The FileFmt and ListName may be different for each AREA if you want. Here's how it all works: If you do nothing, the programs will create FILES.BBS in the "toss-to" directory as always. If you add the keyword LISTNAME, followed by a "simple" (ie. - without drive:\path\) filename, TICK and HATCH will use that filename in each "toss-to" directory. If you follow LISTNAME by a complete filespec, then the FILES.BBS type file will be named what you want, and will also be created in the specified directory, instead of the default of the "toss-to" direc- tory. This would allow you to send *all* areas descriptions to the *same* description file, as is done for RBBS. Last ... If you follow LISTNAME with a drive:\path\ ONLY, you will get the default "FILES.BBS" filename in the specified directory. Here are some examples of LISTNAME: LISTNAME RBBS.FIL - gives you a file called "RBBS.FIL" in each "toss-to" directory. LISTNAME C:\files\TBBS.TXT - This will give you a single file named TBBS.TXT in the C:\files\ directory for all AREAs (unless over- ridden by a LOCAL keyword - see below). LISTNAME c:\foo\ - This will give you a single FILES.BBS in directory c:\foo\ for all areas (unless overridden with a LOCAL). You may, as before, choose an alternate line format with the "ListFmt" keyword. The format you select serves as the default format for any areas not overriding it with a LOCAL command. 11 TICK v1.30 Local Area Keywords You may also have differing files.bbs-type filenames and direc- tory locations for specific areas. You accomplish this by the "LOCAL" keyword in the area definition. AREAs were previously defined as the keyword "AREA", followed by the "toss-to" directory, the AREA's tag, and the (optional) secondary tag. This line was followed by one or more lines of "addresses - passwords - flags". The area ended at the first line not in the stan- dard "Address-PW-Flags" format. This format will still work, but you may now have additional lines between the "AREA" line and the address lines, transforming the AREA line into an area definition BLOCK, in- stead of LINE. The additional lines MUST begin with the keyword LOCAL. NOTE: IF YOU HAVE ANY LINES (INCLUDING BLANK LINES) BETWEEN THE "AREA" LINE AND THE ADDRESS LINES, AND THE LINES DO NOT BEGIN WITH THE KEYWORD "LOCAL", THE AREA WILL END RIGHT THERE, AND NO NODES WILL BE ASSOCIATED WITH THAT AREA! After the "LOCAL" keyword, there are presently defined two pos- sible keywords: LISTNAME, and LISTFMT. They are defined as described above for the global defaults above. If you do not define a LOCAL for a certain area, then that area defaults to the name or format defined globally, or to FILES.BBS in the toss-to directory, and "%3:-13 %1" for the format. Examples follow: AREA c:\file\softdist SOFTDIST LOCAL LISTNAME f:\farm\animal.bbs LOCAL LISTFMT %3:-13 Hello there %1 1:266/21 password C* 2:261/662 hitom C AREA c:\file\beans BEANS LOCAL lISTNAME Foo.txt 7:26/67 whomi H 1:266/13 wham C* The first example creates an area with 2 listed nodes. The "files.bbs" for that area will be called "animal.bbs", and will be lo- cated in the directory "f:\farm". The Line format will be the filename in a left justified 13 character field, followed by the con- stant text "Hello there", followed by the description text. The area ends after the second node, because there is a blank line there. 12 TICK v1.30 The second area is tagged "BEANS". The "files.bbs" will be called "Foo.txt", and will be located in the "toss-to" directory called "c:\file\beans". The format will default to the format defined in the global LISTFMT statement, or to "%3:-13 %1 if none has been defined. -------- CRC-32 CRC-32 checking is present in TICK/HATCH. All files processed by either program will have the CRC computed and present in the outbound TIC's. If you add the keyword "CRC" to your CFG file, then inbound TIC's that have CRC's in them will have that CRC compared to the com- puted CRC. If the numbers don't match, the file will fail. TIC's received from older versions, having no CRC line, will be spared this check, but outbound TIC's will still have the CRC line in either case. One negative side effect of this is that significant time is required to calculate the CRC. I feel that the added safety is worth it, however. If you would like the CRC value to appear in your log file, add the keyword "LOGCRC" to your TIC.CFG. If you choose to log your CRC's, the value in the log will be followed by a star (*) if the in- bound file also had a CRC in the TIC. If you want to also save the CRC in the *.DUP file after each filename, add the keyword "CRC2DUP". Right now al this will do is make your DUP files larger, but it might be useful for future develop- ments. Having the CRC compared to the CRC present in the inbound TIC can cause problems in at least one situation. If you run a program like STRIPZIP to eliminate potentially dangerous ASCII sequences from received ZIP files, the CRC of the file you received will no longer match the CRC in the TIC file. To get around this problem, there is a (previously undocumented though present in the betas) command line switch for this situation. What you do is to NOT define "CRC" in your TIC.CFG file. When you receive new files, first run TICK with the command line switch "/OC". That will cause TICK to test the un- modified file's CRC against what is present in the TIC. (It also tests for proper password, proper FROM address, etc.) If the CRC's do not match, the TIC file is renamed to "*.BAD". If all is well, the file is not further processed, and outbound TICs/FLEs are *not* created. This mode is a "check-only" mode. After running TICK with the /OC switch, you can then run STRIPZIP. After Stripzip, have the batch file call TICK, this time *without* the /OC switch. Tick will 13 TICK v1.30 process normally, and will ignore the CRC in the inbound TIC's, since you don't have CRC in the TIC.CFG. The new CRC generated in the out- bound TIC's will be proper for the file as you are sending it. AKA's Several of you have asked for this feature. Here's how it works: For each alternate address you are known by, add a line to the CFG file beginning with the keyword "AKA", and followed by your ad- dress in [zone:]net/node format. If the zone is not present, it defaults to the default zone (the first ZONE statement in the CFG file). For example: AKA 1:1/313 When I place this in my CFG file, I will add both my main address of 1:266/12, and 1:1/313 to the seenby list in my outbound TIC's and Fle's. You may specify for each node you send to, what address you are sending from. All addresses still appear in the seenbys. Here's how it works: There is an additional flag for the node's flag field (the field where you specify if that node is <C>rash, <H>old, <*>, etc). If you want that node to receive from you as your primary address, you need make no change. If you want to send to that node as an AKA, the new flag is "A", followed by the number of the AKA to use (from 0 to F in Hex). The number corresponds to the order that you have defined AKA's in your CFG file ... The first AKA is "0", the second is "1", etc. NOTE THAT THE NUMBERING STARTS AT '0', NOT AT '1'. For example, to send to node 2:512/26 using my first AKA of 1:1/313, I would set the node up like this: 2:512/26 Password HA0* This will instruct TICK to communicate with that node as 1/313, send it HOLD, and accept files from him as well. Since I will be now sending to 512/26 as 1/313, he must set up my node as 1/313 in his TIC.CFG, and need NOT set up the dummy 266/12 as was previously re- quired. The number after the "A" must be a single character, and must not be separated from the "A" by a space 14 TICK v1.30 USE CAUTION WITH SENDING TO OTHERS AS YOUR AKA! If not carefully used, this will increase the likelyhood of a DUP ring. It's recom- mended that AKA's only be used when crossing between zones at a desig- nated "gate", which does not loop back into the first zone somewhere else. Oh yes ... The limit on AKA's is 16 of 'em. Finding the CFG file The TICK program, and accompanying HATCH program should be placed in any convenient directory. When run, both programs need to find the configuration file. Tick / Hatch first looks to see if you have en- tered the configuration file as a command line parameter. If you choose this method, the following form applies: TICK /Cc:\other.cfg The "/C" may be upper or lower case. If there is no command line parameter, TICK next looks to see if you have set the environmental variable TIC as in: TIC=C:\OTHER.CFG Where C:\OTHER.CFG is the configuration file to be used this run. If neither option is chosen, then the default is to use the file TIC.CFG in the current directory. If no such file is available, TIC aborts with a fatal error. In addition to the CFG file, you should set the TZ environmental variable to the difference between local time and GMT. This is the same variable used by Opus and many other bbs-related programs. For the Eastern time zone, it would be set to TZ=EST5EDT. In your batch file, have the line: SET TZ=EST5EDT This variable is not needed for TICK to run; but if the time- stamps in the PATH statement are to be meaningful, it should be set. If it is NOT set, it defaults to the Pacific time zone. This was not MY decision, but rather was the decision made by Microsoft when they coded their comilper. When time-released versions of TICK become available, it will be necessary to set this variable so that the release time will be proper. WARNING: Bob Germer pointed out to me that this form of TZ variable can cause problems for Opus, depending on what version of DOS you run. If you experience problems with other programs using this TZ string, you could use the form: SET TZ=EST5 15 TICK v1.30 This will work for both TICK and Opus. Its disadvantage is that you will need to change the "5" to "4" during daylight savings time. The first format will give the correct results within TICK in standard and in daylight time zones without the need to manually alter the string. An alternative would be to set the EST5EDT format in your batch file that calls TICK, and reset it to the EST5 format after TICK has been run. Tick and other file-echo software The TIC file format should be compatible with the files produced by Randall Greylock's UPCL program. TICK also offers support of the FLE file created by Ron Bemis' FLEA. TICK does NOT currently provide for time-released files as Flea 2.2 does, but will preserve the release time information when acting as an intermediate between two systems running Flea 2.2. Time release capability is planned for a future release. HATCH Files are started into a file-echo with the program HATCH. HATCH uses the same configuration file (see below) as TICK, and the CFG file must be present for either program to run. File-echos are set up in AREAs, each AREA having an echo tag, similar to the echotag in echomail. An AREA name may be up to 8 characters, and must consist of characters legal in a dos filename. You may have multiple AREAs (and probably will). When you run HATCH, you need to tell it what AREA you are hatching the file in, the file's name and location, and the description to put in the FILES.BBS of the directory associated with that AREA. This may be done interactively, or from the command line. If you choose to use hatch interactively, as most do, just enter HATCH (optionally followed by the CFG file to use, as in : HATCH /cOTHER.CFG Hatch will prompt you for the filename. HATCH prefers that the file you HATCH to be in the "toss-to" directory associated with the AREA at the time of hatching. If you MUST hatch from a directory nor- mally NOt associated with that AREA, You will need to include the full pathspec as in previous versions of HATCH. If you place the file in the "toss-to" directory first, you need only give the filename when you hatch. If the file is not found, hatch will say so and abort. Othewise it will prompt you for the AREA (file echo tag) you want to send the file in, and the DESCRIPTION that will be placed in the FILES.BBS for that file. It is recommended that the file to be hatched be located 16 TICK v1.30 in the "destination directory" normally associated with that AREA. If it is NOT, it will still send the file just fine and the FILES.BBS will be updated. However, your BBS will likely report that the file is MISSING. If you choose to enter all or some of the information from the command line, there are 4 additional command line switches: /A , /F, /ON, and /D. The /A switch specifies the file-echo AREA to hatch into. The /F switch specifies the file to hatch. The /D switch specifies the description line to use for the FILES.BBS. Like the "/C", all the new parameters are NOT separated from the switch-letter. Ie: The area SOFTDIST would be written as /aSOFTDIST instead of /A SOFTDIST. An example: To hatch the file FOO.ext in area SOFTDIST with the description line "This is the Description", use the following line: HATCH /aSOFTDIST /fFOO.ext /dThis is the description >> logfile.log Any parameters NOT specified on the command line are prompted for as before. If the /D description switch is used, it must be the last switch on the command line, as it is of variable length and number of tokens (words). The description may be up to 80 characters long, but it is strongly recommended that the description be kept below 50 characters. In conjunction with DAYNBR.ARC, this should make hatching of nodediffs effortless and automatic with the proper batch. The above example shows another design feature of TICK and HATCH. Both are designed to allow redirection of output to a log file for review of what has happened. The sign-on credits will go to the screen, not the log. The log is formatted to match the form of the Binkley and Opus logs. In fact, I use the same log for Binkley, Opus, and Tick here. The ">>" redirects the log output as an append. Hatch allows you to re-enter an incorrectly entered area or filename. The AREA comes first, then the filename, then the descrip- tion when running in the interactive mode. (The AREA *must* precede the filename in interactive mode, since TICK needs to know where to look for the file when you don't enter the path). Having HATCH loop back for a file not present or a misspelled area name could present problems for those of you who use batch processing and don't want the hatch to "hang" looking for keyboard in- put that is never coming. For this reason there is a "NOWAIT" option available. Either put the keyword "NOWAIT" in the CFG file, or have the batch call HATCH with the switch "/ON" (without the quotes. The "O" stands for "Option", by the way.) 17 TICK v1.30 Command Line Switches There are a number of command line switches that are useful. At the present time these consist of /C /A /F /D /ON /OC. They are defined as follows: "/Cc:\subdir\other.CFG" This will define the file c:\subdir\other.cfg as the CFG file to use for this run of TICK or HATCH. "/Asoftdist" This tells HATCH that the AREA you are HATCHing into is the area called SOFTDIST. It is ignored when used with TICK. "/Fc:\utility.ext" This tells HATCH that the file you are HATCHing is c:\utility.ext "/DThis is a useful utility" This will set the DESCription to "This is a useful utility". It is useful only with HATCH, and if used must be the LAST switch on the command line. "/ON" This switch tells HATCH to not loop back for corrected input when it can't find the FILE or AREA you are HATCHing. "/OC" Runds TICK in the "check mode". Errors will set the inbound *.TIC to *.BAD, but no tossing or forwarding of files occurs. Error Levels Tick and Hatch exit with the following errorlevels if there is a fatal error: 1 = Error reading a file 2 = Error Writing a file 3 = Out of Memory 4 = Invalid CFG file 5 = Invaild PATH or filespec 6 = Processing Error WHAT'S NEW? IF YOU ARE UPGRADING FROM AN EARLIER VERSION OF TICK, PLEASE READ THIS SECTION CAREFULLY ... THIS VERSION MIGHT REQUIRE MODIFICATIONS TO YOUR CONFIGURATION FILE AND BATCH FILES. 18 TICK v1.30 * DOCUMENTATION ERROR - Previous versions of TICK indicated that the TZ environmental variable could be defined in the form: TZ=EST+05. This may have been OK with earlier versions of MSC, but this form creates errors when used with MSC 5.1. The correct method is shown above. * Corrects a bug where an area defined with only one node, and that node bearing the "*" and "&" flags, would result in the file being properly tossed but the inbound TIC not being deleted. * Added code to do a simple test to see if the AREA directory you are about to toss to happens to be the same as the IN directory you are tossing from. In such a case, the file may be deleted for good. Now, TICK will abort with a errorlevel 4 fatal error and indicate why. This is a simple-minded test, which will not detect SUBSTituted direc- tories, but should help protect new users from shooting themselves in the foot. * Fixed a bug where a received FLE file with a pre-release date would not maintain the pre-release time in the echoed FLE's and TIC's, and would alter a random memory location in the data segment. * Fixed a bug that might have allowed a non-starred node to send you a file under certain rare circumstances. * The definition of a QDIR directory in the CFG file is now a re- quirement. So far, this doesn't do anything, but will be important in a future release. Just point it to an empty directory that won't be used for anything else. Be aware that if you need to do a RESTORE on your disk, you might need to re-create the QDIR directory, as some backup/restore programs fail to restore empty directories. * There is a slight change in the way that the new TIC and FLE files are named. They will still have the same general format, but the nameing will occur faster than the previous 1 per second if your machine is fast enough. * TICK now supports variable formats of the FILES.BBS type file. You may have different formats for each area, send ALL areas to a single FILES.BBS file, or use names other than "FILES.BBS" if it fits your purpose. * Fixed bug in which a a received TIC or FLE would be renamed to ".BAD" instead of being deleted if there were no systems to send the file to (all systems already listed in the Seenbys). * Tick will now indicate the original AREA of a received file in the log. 19 TICK v1.30 * Tick/Hatch can now display to the screen and to the log file at the same time. There is a new keyword "SCREENLOG". If this keyword is present in the TIC.CFG, TICK will send the log to the screen, as well as to whatever you are re-directing output to. If you are NOT keeping a log by redirecting TICK's output, then do NOT use this keyword, or you will get double (nearly) everything on the screen. * NOTE: HATCH now prefers the file you HATCH to be in the "toss-to" directory associated with the AREA at the time of hatching. If you MUST hatch from a directory normally NOt associated with that AREA, You will need to include the full pathspec as in previous ver- sions of HATCH. If you place the file in the "toss-to" directory first, you need only give the filename when you hatch. * TICK now attempts to use a larger buffer when copying files. This should dramatically improve speed when you are moving a large file to a different logical drive. * The timestamp in the path created by TICK now is consistent with the timestamp in the path line created by HATCH. * CRC-32 checking is now in TICK/HATCH. * HATCH will now not allow you to attempt to send a directory name or volume label as a file. * Hatch will now allow you to re-enter an incorrectly entered area or filename. The AREA comes first, then the filename, then the description when running in the interactive mode. (The AREA now *must* precede the filename in interactive mode, since TICK needs to know where to look for the file when you don't enter the path). * Fixed the faulty informational message that was generated when all listed systems had already seen the file. * Have implemented a form of AKA's into the program. * Fixed an incorrect memory allocation of the AREA address list structure. You may now have 40 nodes per area, instead of 39. (Nobody noticed this, so I imagine that nobody is sending to that many nodes in a single area). * Fixed HATCH so that if you are re-directing output to a log file, you still see the prompts when necessary. * Tick will now display the faulty path when there is a bad path specified for an AREA. * TICK now does some additional testing of its temporary files to try to determine if you have run out of disk space on the TEMP drive when writing them. I believe that this is the cause of the infamous 20 TICK v1.30 26 byte TIC's that a certain nameless individual likes to send around to see if we are paying attention. :-) It won't catch EVERY case, as there is one out of 512 times that the file will have self-flushed ex- actly at the last byte of the final fprintf. Parting Comments I hope you find this utility useful. Tick may be used in any non-commercial environment free of licensing charges. It may be freely distributed so long as there is no charge for it and it is dis- tributed only in the original archive. There is NO warranty with this product, and I assume no responsibility for any damages it might do to your system, nor any consequential damages. In other words, you assume all risks should you decide to use it. It is working well on my system, and on the systems of those brave sysops who have helped me beta test it. I want to thank George Peace (1:13/13), Jeff Myers (1:266/13), Bob Germer (1:266/21) , Don Dawson (1:141/730), Randall Greylock (1:321/202), Mike Fuchs (1:266/71), Tom Hendricks (1:261/662), and many others for their assistance in testing. Special thanks go to Bob Hartman (1:132/101), for sending code to allow us all those wonderful variations on the FILES.BBS-type file. I'm certaint that those of you who run a BBS that can't use a FILES.BBS are especially grateful as well. I also would like to thank Jeff Nonken (1:103/322) for the code which allows the paths set in the environment to end either with or without a backslash, Scott Dudley (1:148/314) for help with the com- mand line parser, and Jim Nutt for the MSG structure I used in im- plementing the "Seadog-type" file attaches. I should also mention that Binkley is a trademark of Spark Software/Bit Bucket Software, Flea is a trademark of Ron Bemis, Opus is trademarked by Wynn Wagner,III, and Seadog is a trademark of SEA (System Enhancement Associates). (If I spelled any of these wrong or got any of these credits wrong, I'm certain someone will tell me sooner or later.) Other names mentioned may be trademarked by their respective owners. Barry Geller Maple Shade Opus 1:266/12 609-482-8609 21